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(54) Application certification for an international cryptography framework 



(57) An application which requests cryptographic 
services from various service elements within an inter- 
national cryptography framework is identified through a 
certificate to protect against the misuse of a granted 
level of cryptography. A cryptographic unit, one of the 
framework core elements, builds several certification 
schemes for application objects. One or more methods 
are provided that establish a degree of binding between 



an application code image and issued certificates using 
the framework elements. Within the framework, the 
application is assured of the integrity of the crypto- 
graphic unit from which it is receiving services. One or 
more mechanisms are provided which allow the appli- 
cation to validate that the cryptographic unit has not 
been replaced or tampered with. 
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Description 

BACKGROUND OF THE INVENTION 

TECHNICAL FIELD 

The invention relates to cryptography. More particu- 
larly, the invention relates to a mechanism for validating 
an application image as it is installed on a system with 
respect to the binding of the application to a certificate, 
as well as validating the system service element upon 
which the application image is installed. 

DESCRIPTION OF THE PRIOR ART 

Customers of large computer systems are typically 
multinational corporations that want to purchase enter- 
prise wide computer based solutions. The distributed 
nature of such organizations requires them to use public 
international communications services to transport data 
throughout their organization. Naturally they are con- 
cerned about the security of their communications and 
seek to use modern end-to-end cryptographic facilities 
to assure privacy and data integrity. 

The use of cryptography in communications is gov- 
erned by national policy and unfortunately, national pol- 
icies differ with respect to such use. Each national 
policy is developed independently, generally with a 
more national emphasis rather than international con- 
siderations. There are standards groups that are seek- 
ing to develop a common cryptographic algorithm 
suitable for international cryptography. However, the 
issue of international cryptographic standards is not a 
technical problem, but rather it is a political issue that 
has national sovereignty at its heart. As such, it is not 
realistic to expect the different national cryptography 
policies to come into alignment by a technical standard- 
ization process. 

The issue of national interests in cryptography is a 
particular concern of companies that manufacture 
open-standards-based information technology products 
for a worldwide market. The market expects these prod- 
ucts to be secure. Yet, more and more consumers of 
these products are themselves multinational and look to 
the manufacturers to help them resolve the international 
cryptography issues inhibiting their worldwide informa- 
tion technology development. The persistence of unre- 
solved differences and export restrictions in national 
cryptography policies has an adverse impact on interna- 
tional market growth for secure open computing prod- 
ucts. Thus, it would be helpful to provide an 
international framework that provides global information 
technology products featuring common security ele- 
ments, while respecting the independent development 
of national cryptography policies. 

Nations have reasons for adopting policies that . 
govern cryptography. Often these reasons have to do 
with law enforcement and national security issues. 



Within each country there can be debates between the 
government and the people as to the Tightness and 
acceptability of these policies. Rather than engage in 
these debates or try to forecast their outcome, it is more 

5 practical to accept the sovereign right of each nation to 
establish an independent policy governing cryptography 
in communication. 

Policies governing national cryptography not only 
express the will of the people and government, but also 

io embrace certain technologies that facilitate cryptogra- 
phy. Technology choice is certainly one area where 
standardization can play a role. However, as indicated 
earlier this is not solely a technical problem, such that 
selection of common cryptographic technologies alone 

is can not resolve the national policy differences. 

A four-part technology framework that supports 
international cryptography, which includes a national 
flag card, a cryptographic unit, a host system, and a net- 
work security server is disclosed by K. Klemba, R. Mer- 

20 ckling, International Cryptography Framework, in a 
copending U.S. patent application serial no 08/401 ,588, 
which was filed on 8 March 1995. 

The framework supports the design, implementa- 
tion, and operational elements of any and all national 

25 policies, while unifying the design, development, and 
operation of independent national security policies. The 
framework thus gives standard form to the service ele- 
ments of national security policies, where such service 
elements include such things as hardware form factors, 

30 communication protocols, and on-line and off-line data 
definitions. 

Fig. 1 is a block diagram of the international cryp- 
tography framework 10, including a national flag card 
1 2, a cryptographic unit 1 4, a host system 1 6, and a net- 

35 work Security server 18. Three of the four service ele- 
ments have a fundamentally hierarchical relationship. 
The National Flag Card (NFC) is installed into the Cryp- 
tographic Unit (CU) which, in turn, is installed into a 
Host System (HS). Cryptographic functions on the Host 

40 System cannot be executed without a Cryptographic 
Unit, which itself requires the presence of a valid 
National Flag Card before it's services are available. 
The fourth service element, a Network Security Server 
(NSS), provides a range of different security services 

45 including verification of the other three service ele- 
ments, and thus acts as a trusted third party. 

Fig. 2 is a perspective view showing the four basic 
elements of the framework, including the cryptographic 
unit 1 4 and several national flag cards 1 2, a host system 

so 16, and a national security server 18. In the following 
sections each service element is discussed in greater 
detail. 

NATIONAL FLAG CARD (NFC). The NFC 12 is a 
small stamp sized (25 x 15 mm) ISO 7816-type smart 
55 card, i.e. a one chip computer 26 having a non-volatile 
memory. The NFC is mounted on a rigid substrate and 
sealed in a tamper-proof package. The NFC is typically 
produced independently and distributed by National 
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agencies (e.g. United States Postal Service, German 
Bundespost). National agencies may also license NFC 
production and distribution to private industry. 

The action of the NFC service element is to enforce 
a nation's policy governing the use of cryptography. An s 
NFC is a complete computer that can be constructed as 
a multi-chip architecture to include custom integrated 
circuits. It also would include tamper resistance and 
unique identification features, making unauthorized 
entry or duplication impossible. For example, the NFC 10 
could be sealed in such a way that opening its package 
would destroy any integrated circuit or data inside. The 
NFC could require receipt of an encrypted authorization 
issued by the National Security Server. All services of 
the NFC are provided via standard ISO 7816 message is 
exchanged protocol between the NFC and other service 
elements. This format is identical to the smart card used 
in Europe to support GSM in cellular voice services. 

CRYPTOGRAPHIC UNIT (CU). The cryptographic 
unit is a tamper-resistant hardware component 20 
designed to provide protected cryptographic services 
under the strict control of an NFC. Cryptographic units 
would be produced competitively by system vendors 
and third parties and be free of import and export 
restrictions. Because the cryptographic unit includes 25 
critical elements of security such as encryption algo- 
rithms and keys, it is likely that it would be certified (e.g. 
NISI NCSC. or ITSEC Certified) for customer assur- 
ance. It is a feature of this embodiment of the invention 
that the cryptographic unit does not contain any govern- 30 
ing policy other than its dependence upon a NFC. This 
component is preferably designed for performance and 
protection with customization for a given Host System. 

HOST SYSTEM (HS). The HS is identifiable as the 
hardware component that delivers secure information 35 
technology services directly to the user. HSs are typi- 
cally a general purpose information technology device 
and would be produced competitively in a wide open 
market. Examples include personal digital assistants, 
personal computers, workstations, laptops; palmtops, 40 
networked servers, main frames, network printers, or 
video display units, as well as embedded systems for 
control and measurement. The function of the HS serv- 
ice element in the framework is to provide an Applica- 
tion Programming Interface (API) for accessing the 45 
cryptographic unit service element. Preferably, crypto- 
graphic unit support is provided as an option available 
on the HS. 

NETWORK SECURITY SERVER (NSS). The NSS 
is a network node designed and designated to provide so 
trusted third party Security services. For example, any 
network access, such as via modems 30, 32 over a net- 
work 34, must be authenticated by the NSS. In the con- 
text of national security, NSSs are preferably developed, 
owned, and operated by government agencies. Some of 55 
the functions provided by the NSS service element 
include service element authentication, message stamp 
authentication, national policy enforcement, and crypto- 



graphic key distribution. The importance of the NSS can 
rise sharply in environments where a strong degree of 
verification is prerequisite to cryptographic use. The 
NSS also plays a significant role in the interoperability of 
differing National cryptographic policies. 

Scope Of The Framework. The scope of the frame- 
work is largely defined by the scope of the NFCs. The 
basic scope of the NFCs is that of a domain. A domain 
can be as large as worldwide and as small as a busi- 
ness unit. At the domain level there is no unique distinc- 
tion among its members. While this framework primarily 
focuses on national and international domains (e.g. 
France, Germany, United States, United Kingdom, 
European Commission, NATO, North America, G7) 
other domains or sub-domains are also considered. For 
example, industry domains {e.g. Telecom, Healthcare, 
Financial Services, Travel), corporate domains (e.g. 
Hewlett-Packard, Ford Motor Company, CitiBank), 
association domains (e.g. IEEE, ISO, X/Open), service 
domains (e.g. Compuserve, America On-Line), and 
product domains (e.g. Lotus, Microsoft, General 
Motors, Proctor & Gamble). 

Beyond domains and subdomains the scope of the 
framework can optionally be expanded to define unique- 
ness within a domain. Again it is the NFCs that make 
this narrower scope possible. Providing uniqueness 
means allowing for the transfer of unique or personal 
data to be transferred to the NFC either at the time of 
purchase or at the point of initial validation. NFCs are 
considered anonymous when dealing at the domain 
level. When uniqueness is added, NFCs are no longer 
anonymous. 

Interconnect Of Framework Elements. The inter- 
connection of service elements (e.g. NFC, CRYPTO- 
GRAPHIC UNIT HS, NSS) of this framework is 
accomplished by the adoption of standard Application 
Programming Interfaces (e.g. X/Open, OSF) and indus- 
try standard protocol exchanges {e.g. TCP/IP, ISO, 
DCE, X.509). The interconnection of elements may be 
synchronous (i.e. on-line), asynchronous (i.e. off-line), 
local (e.g. runtime library), remote (e.g. RPC) or any 
combination of these. For example, a policy that 
involves personalization of NFCs could perform a one 
time authorization function via a NSS making it unnec- 
essary for future on-line verification with an NSS until 
the NFC expires. 

Beyond the physical interconnection of the frame- 
work's service elements lies the message exchange 
between the elements and the actual services provided 
and requested via this message exchange. Fig. 3 illus- 
trates the message exchange paths, between an NFC 
12 and a cryptographic unit 14 (path 35). between the 
cryptographic unit 14 and an HS 16 (path 36), and 
between the HS 16 and an NSS 18 (path 37). A virtual 
connection 38 exists between the NFC and the NSS. 
Messaging protocol between the HS and the crypto- 
graphic unit along the path 36 are best taken from cryp- 
tographic API standardization efforts (e.g. NSAs 
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Cryptographic API, Microsoft's Cryptographic API). The 
messaging protocol between the cryptographic unit and 
the NFC along the path 35 is categorized into two 
groups: initialization protocols, and operational proto- 
cols. The initialization protocols must be successful 
before operational protocols are active. 

Consequently, it would be useful to provide a com- 
mon, accepted cryptography framework, wherein inde- 
pendent technology and policy choices can be made in 
a way that still enables international cryptographic com- 
munications consistent with these policies. Critical to 
the implementation of the framework is the provision of 
a fundamental technology that allows the production of 
the various service elements. While various implemen- 
tations of the service elements are within the skill of 
those versed in the relevant art, there exists a need for 
specific improvements to the state of the art if the full 
potential of the framework is to be realized. 

For example, it would be advantageous to include 
within the framework a system the establishes that an 
application is a legitimate application having authoriza- 
tion for a requested class of service. It would also be 
advantageous for the application to verify that the serv- 
ice element is a legitimate recipient of the application 
image and service requests. It would additionally be 
advantageous if such system operated in accordance 
with a Security paradigm that required at least a tamper 
proof transport mechanism, such as a certificate, and a 
mechanism for establishing and maintaining continuity 
during a particular transaction. 

SUMMARY OF THE INVENTION 

The invention resides within a secure system, such 
as an international cryptography framework, for exam- 
ple which allows manufacturers to comply with varying 
national laws governing the distribution of cryptographic 
capabilities. In particular, such a framework makes it 
possible to ship worldwide cryptographic capabilities in 
all types of information processing devices (e.g. print- 
ers, palm-tops). Within the framework, a cryptographic 
unit contains several cryptographic methods (e.g. DBS, 
RSA, MD5). 

It is a fundamental requirement of the framework 
that an application which requests cryptographic serv- 
ices from the framework service elements is identified 
through some form of certificate to protect against the 
misuse of the granted level of cryptography. The crypto- 
graphic unit, one of the framework core elements, can 
be used to build several certification schemes for appli- 
cation objects. The invention provides various methods 
that establish a degree of binding between an applica- 
tion code image and issued certificates using the frame- 
work elements. 

Another fundamental requirement of the framework 
is that the application is assured of the integrity of the 
cryptographic unit from which it is receiving services. 
The invention provides various mechanisms that allow 
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the application to validate that the cryptographic unit 
has not been replaced or tampered with. 

BRfEF DESCRIPTION OF THE DRAWINGS 

5 

Fig. 1 is a block diagram of an international cryptog- 
raphy framework, including a national flag card, a 
cryptographic unit, a host system, and a network 
security server; 

10 

Fig. 2 is a perspective view showing the four basic 
elements of the framework, including a crypto- 
graphic unit and several national flag cards, a host 
system, and a national security server; 

15 

Fig. 3 illustrates the message exchange paths, 
between an NFC and a CU, between a CU and an 
HS, and between an HS and an NSS; 

20 Fig. 4 is a block schematic diagram of a crypto- 
graphic unit according to the invention; 

Fig. 5 is an overview of the main software architec- 
ture elements of a framework according to the 
25 invention; 

Fig. 6 is a block diagram of the key elements of a 
policy scheme in which an application is granted a 
class of services by an application domain author- 
so ity, where such class of services ultimately define 
the level of cryptography allowed in the application 
according to the invention; 

Fig. 7 is a block diagram that illustrates the certifica- 
35 tion requirements of a framework according to the 
invention; 

Fig. 8 is a block schematic diagram that illustrates 
the flow of events by which an application intro- 
40 duces itself to a cryptographic unit according to the 
invention; 

Fig. 9 is a block schematic diagram that illustrates 
the steps executed during the execution stage 
45 according to the invention; 

Fig. 10 is a schematic representation of a software 
touchpoint according to the invention; 

so Fig. 11 is a schematic representation of a unstruc- 
tured and a structured instruction level software 
touchpoint according to the invention; 

Fig. 12 is a block schematic diagram that illustrates 
55 the steps executed during the manufacturing stage 
according to the invention; 

Fig. 13 is a block schematic diagram that illustrates 
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the steps executed during the installation stage 
according to the invention; 

Fig. 14 is a block schematic diagram that illustrates 
the steps executed during the execution stage s 
according to the invention; 

Fig. 15 is a block schematic diagram that illustrates 
the memory hierarchy with respect to the software 
touchpoint resolution according to the invention; w 

Fig. 16 is a block schematic diagram that illustrates 
the memory hierarchy with respect to the software 
touchpoint resolution according to the invention; 
and 15 

Fig. 17 is a block schematic diagram that shows 
instruction level touchpoint support inside the host 
system processor according to the invention. 

20 

DETAILED DESCRIPTION OF THE INVENTION 

National cryptography policy often varies by indus- 
try segment, political climate, and/or message function. 
This makes it difficult to assign one uniform policy 25 
across all industries for all time. Consequently, the flexi- 
bility of a cryptography framework that incorporates a 
national flag card is very attractive. The invention is 
therefore primarily directed to resolving problems sur- 
rounding international cryptography. However, the 30 
invention is readily applicable to any environment that 
requires validation of an application's authenticity 
and/or privilege; and that requires that the application 
be assured that it is using the services of an authorized 
secure, cryptographic processor. 35 

The preferred embodiment of the invention is con- 
cerned with application certification within a framework 
such as that disclosed by K. Klemba, R. Merckling, 
Internationa/ Cryptography Framework, in a copending 
U.S. patent application serial no 08/401,588, which was 40 
filed on 8 March 1995. It is a fundamental requirement 
of the framework that an application which requests 
cryptographic services from the framework service ele- 
ments is identified through some form of certificate to 
protect against the misuse of the granted level of cryp- 4s 
tography. The cryptographic unit, one of the framework 
core elements, can be used to build several certification 
schemes for application objects. The invention provides 
various methods that establish a degree of binding 
between an application code image and issued certifi- so 
cates using the framework elements. 

Another fundamental requirement of the framework 
is that the application is assured of the integrity of the 
cryptographic unit from which it is receiving services. 
The invention provides various mechanisms that allow 55 
the application to validate that the cryptographic unit 
has not been replaced or tampered with. 

As discussed above, the framework allows manu- 



facturers to comply with varying national laws governing 
the distribution of cryptographic capabilities. In particu- 
lar, such a framework makes it possible to ship world- 
wide cryptographic capabilities in all types of 
information processing devices (e.g. printers, palm- 
tops). 

The four basic elements of framework (as dis- 
cussed above) are listed below with a brief description 
of each. 

Cryptographic Unit. The system or unit that con- 
tains a cryptographic unit supports an application pro- 
gramming interface to a cryptographic unit. It also 
supports applications that are security aware and that 
use the cryptographic unit. These applications and/or 
subsystem layers are bound tightly to the cryptographic 
unit by use of a certificate. 

The cryptographic functions are dormant and can- 
not be used by the host system until activated by a pol- 
icy. The cryptographic functions that are included in the 
cryptographic unit are determined by the requirements 
of the application in which the invention is used. The 
cryptographic unit is tamper resistant to protect any 
keys that may be stored therein. It is the responsibility of 
the cryptographic unit to maintain contact with a policy. 
Failing to do so results in the decay of the cryptographic 
unit. 

Policy (also referred to a the "National Flag Card" 
and "Policy Card"). The policy is the system or unit that 
contains cryptography usage policy. Specifically this 
element of framework contains parameters that govern 
the use of cryptography in a specific cryptographic unit. 
Furthermore, this element is responsible for responding 
to a cryptographic unit heartbeat challenge. 

Network Security Server. The network security 
server is the system or unit that acts as a trusted third 
party to provide networked services to host systems, 
cryptographic unit, and policies. These services include, 
for example, policy enhancements, unit verification, 
adjustments to authorizations, and key management 
services. 

The framework architecture rests on the following 
basic assumptions about the core elements: 

The cryptographic unit cannot provide the host sys- 
tem with any cryptographic functions without being 
in contact with a policy. 

The policy has no access to user data being proc- 
essed within the cryptographic unit. 

The cryptographic unit(s) which is controlled by a 
given policy is deterministic, i.e. every event, act, 
and decision of the cryptographic unit is the inevita- 
ble consequence of antecedents that are independ- 
ent of the policy. 

The cryptographic unit or policy can request serv- 
ices of a national security server. 
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One key element of the framework is the crypto- 
graphic unit. An implementation of the cryptographic 
unit provides a set of services to the host system, as fol- 
lows: 

Cryptographic functions. The main purpose of the 
cryptographic unit is to provide cryptographic func- 
tions. The unit hosts hardware and software to 
carry out the defined cryptographic algorithms. It 
also hosts hardware and software which enforce a 
certain cryptographic policy. 

Secure storage. Secure storage allows the storage 
of information in a secure manner inside the crypto- 
graphic unit. This facility is primarily used for the 
storage of key material inside the cryptographic 
unit. Over time, application and subsystem layers 
may also take advantage of this facility by storing 
other non-security related material inside the cryp- 
tographic unit. 

Secure execution. The cryptographic unit allows for 
the execution of code in the secure unit and tamper- 
resistant environment of that unit. Applications and 
subsystem layers may take advantage of this facility 
to implement a portion of their functionality, such as 
security protocol handlers, in this secure environ- 
ment. 

Fig. 4 is a block schematic diagram of a crypto- 
graphic unit architecture. The figure does not refer to a 
specific physical implementation, but shows the main 
elements required inside the cryptographic unit to 
implement this element of a preferred embodiment of 
the invention. 

There are several components which form the cryp- 
tographic unit 14, as follows: 

Central Processing Unit (CPU). The CPU 47 con- 
trols all information flow. Modules downloaded for 
secure execution are executed by the CPU. 

Storage Elements. The cryptographic unit needs 
several storage elements. 

The flash memory 48 is the storage for pro- 
grams and nonvolatile data stored in the cryp- 
tographic unit. 

The ROM storage 49 hosts the bootstrap code 
which executes on reset of the cryptographic 
unit. 

The RAM storage 50 holds the volatile data of 
the cryptographic unit. 

Cryptographic ASIC 52 and random number gener- 
ator 51. These two elements perform the basic 



operations for the cryptographic functions offered 
by the cryptographic unit. 

Bus Logic. The bus logic 53 interfaces the unit with 
5 various interfaces to the host system 16. Two main 

channels exit towards the host system. The control 
channel 42 is used for commands and status mes- 
sages between the calling system and the crypto- 
graphic unit. The data channel 44 performs the 
10 actual data transfer. 

The framework software architecture describes the 
layers of libraries and system elements which are 
needed to implement the framework elements on a 
75 given host system. Fig. 5 provides an overview of the 
main software architecture elements. 

Applications. The application layer 55 is the area of 
user written applications and libraries which need cryp- 
tographic services. Applications may or may not be 
20 aware of these services. In case they are aware, the 
subsystem layer 56 below offers a set of programming 
interfaces to the application. Cryptographically unaware 
applications do not issue any calls themselves, the 
underlying subsystem performs these calls on behalf of 
25 the application. 

Subsystem Libraries And Interfaces. Subsystems 
56 which support cryptographic functions for aware and 
unaware applications also provide APIs to the applica- 
tions. 

30 Most notable APIs include the Microsoft CAPI and 
the X/Open GSS-APl and GCS-API for Unix. Subsys- 
tem libraries are typically organized into application pro- 
gramming interfaces and, shielded through the 
operating system 57, a cryptographic service provider 

35 module. 

The subsystem libraries may also hide the security 
APIs completely from the application. This allows exist- 
ing applications to take advantage of the solution with- 
out being modified. An example is the integration of the 
40 security features into transport level software subsys- 
tems. 

Other elements of this layer provide APIs for 
accessing the cryptographic unit secure storage and 
execution facilities. For example, a database API such 

45 as the ODBC interface could be offered, along with a 
data manager module inside the cryptographic unit to 
provide a tamper resistant database. 

Operating Systems And Drivers. The operating sys- 
tem 57 performs two primary tasks. One task is to iso- 

so late the subsystem programming interfaces from the 
cryptographic service providers. The other task is to 
provide the necessary hardware control through a set of 
drivers which interface with the cryptographic hardware 
in form of hardware drivers. 

55 Cryptographic Unit Subsystem. This layer 59 con- 
tains the hardware implementation and firmware ele- 
ments of the cryptographic functions. The hardware 
typically comes in several form factors, such as a PCI 
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card or a PCMCIA card, to accommodate the different 
hardware platforms and performance requirements. 
The firmware is a set of libraries which implements a 
micro-kernel, e.g. runtime, and the framework function- 
ality, as well as user downloadable software modules 5 
required by a particular application programming inter- 
face. 

Administration. The administration element 54 pro- 
vides a management framework for the entire solution. 
This includes,. for example, middleware components for 10 
administrative functions such as certificate manage- 
ment, application class of service management, and 
downloading of application specific extensions to the 
cryptographic unit. 

The framework introduces the concept of policy 15 
driven cryptography. Application programming inter- 
faces allow selection of desired services based on the 
application certificate. This is in contrast to currently 
available cryptographic programming interfaces. Most 
of the currently available cryptographic APIs are built 20 
around the concept of a cryptographic context. Applica- 
tions establish this context before they can use any 
cryptographic service. For example, the Microsoft CAP I 
offers a programming interface that allows selection of a 
cryptographic service provider (CSP) type, and loads 25 
the software module into the system. An application can 
make calls to the CSP and use its services from that 
point on. There are however, no methods to distinguish 
cryptographic functions based on what the application 
is doing. 30 

The invention implements a scheme by which the 
application is identified when a certificate proves the 
identity of the application and determines the available 
classes of service allocated to that application. There 
several methods for making the certificate available to 35 
the cryptographic unit. 

Certificate passed in each call. The certificate can 
be passed in each call to the CSP. This scheme 
allows for an application which may pass more than 40 
one certificate to pass the appropriate certificate for 
the task that is to be accomplished. For example, if 
an application is allowed to use strong encryption 
for financial transactions and at the same time 
weaker encryption for E-mail functionality, that 45 
application can select dynamically the level of cryp- 
tography by passing the corresponding certificate. 

Certificate passed at initialization time. The certifi- 
cate can also be passed when the link to the CSP is so 
established. An application using multiple certifi- 
cates could establish multiple contexts, one for 
each certificate, and use the appropriate one in the 
cryptographic function calls. 

55 

Certificate implicitly available. The certificate is 
transparently available to the cryptographic layers. 
For example, the application passes its name, 



which is used to index into a registry that contains 
the certificate for the application. 

The invention implements a policy scheme in which 
the application requests a class of services which ulti- 
mately defines the level of cryptography allowed in the 
application. Key elements in this process include the 
application certificate, the class of service, and the 
domain authorities that manage them. 

Fig. 6 shows a high level view of these elements. In 
the figure, there are two domain authorities. The secu- 
rity domain authority (SDA) 62 is responsible for grant- 
ing a set of classes of service (COS) 63 to the 
application domain authority 60. 

The SDA is also responsible for issuing policy cards 
12 which contain the COS information and the touch- 
point data for the cryptographic unit 14. The SDA man- 
ufactures this information upon request from the site 
which installs the cryptographic unit into a host system 
16. 

The application domain authority (ADA) 60 receives 
the COS elements granted by the SDA. The ADA has 
responsibility for issuing application certificates 64 to 
the applications 65 that belong to its domain. An appli- 
cation certificate contains the application ID 67 and the 
granted COS 68 by the ADA 

Applications receive a certificate from the ADA 
which they need to present to the cryptographic unit 14 
to get the desired COS level. The cryptographic unit, 
upon receiving the request, uses the certificate to deter- 
mine whether the application has the right to access the 
requested cryptographic function. If the COS requested 
through the application certificate matches the COS 
granted by the SDA to the ADA and stored in the policy 
card, the request is handled, otherwise it is not handled. 

The touchpoint data 69 are the information stored 
on the policy card which enable the cryptographic hard- 
ware for the defined classes of service. Periodically, this 
information need to be recomputed by the cryptographic 
unit and validated by the policy card. Any mismatch, 
causes the cryptographic capability of the cryptographic 
unit cease to exist. 

TTie network security server (NSS) 18 acts as an 
on-line instrument for policy negotiation and changes to 
the policy information stored on the policy card. If, for 
example, adding a class of service to the set of services 
normally requires the issuance of a new policy card with 
the changed information. Alternatively, the NSS could 
perform the update of the policy card on behalf of the 
SDA. It is important to note, that to prevent a malicious 
application from using a certificate in an unpermitted 
way, applications need to be tightly bound to their certif- 
icates. 

The invention provides a method of validating that 
an application rightfully executes a certain level of cryp- 
tography as it was granted by the application domain 
authority, in form a certificate containing the valid class 
of services. A tight binding of the application to this cer- 
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tificate is therefore a key aspect of the invention. The 
process of establishing this trust is referred to as appli- 
cation certification throughout this document. 

Fig. 7 is a block diagram that illustrates the certifica- * 
tion requirements of a framework according to the s 
invention. Application certification describes two major 
elements of establishing trust between the application 
65 and the cryptographic unit 14, i.e. is the application 
a valid application (72) and is the cryptographic unit a 
valid cryptographic unit (74): w 

The first part deals with the process of analyzing a 
piece of data to determine that it has not been tampered 
with. 

In general, two main classes of objects are of inter- 
est: 15 

The first class deals with the subject of program 
image certification. 

The second class generalizes the process and 20 
applies the concept to a variety of data objects. 

The characteristics of the cryptographic unit, 
namely a tamper-resistant functional unit, allow for the 
construction of general certification methods of arbitrary 25 
data objects. 

The second part views the framework from an 
application perspective, i.e. the application must be 
assured of the identity of the cryptographic unit. The 
process of establishing this kind of trust is referred to 30 
herein as cryptographic unit validation. Cryptographic 
unit validation deals with the process of assuring to the 
application that the cryptographic unit has not been 
tampered with, /. e. has been replaced with a bogus 
cryptographic unit. After the process of cryptographic 35 
unit validation, the application can assume that the cor- 
rect cryptographic unit is performing the requested 
cryptographic services. 

For critical applications, there has long been a need 
to validate that an application has not been tampered 40 
with. Performing this validation usually involves a 
trusted load subsystem. A trusted load subsystem is the 
part of the operating system which is responsible for 
loading a program image into the system memory 
space and while doing that validate that the application 45 
has not been tampered with. Mechanisms, such as a 
checksum over the program image, are often used for 
this purpose. If the checksum does not match the 
checksum stored by the loader subsystem at applica- 
tion installation time, the load fails and the program so 
image is not loaded. 

A trusted loader subsystem cannot exist independ- 
ently from a relationship to the operating system. Trust- 
ing the loader to validate that the application has not 
been tampered with, implies that the operating system 55 
trusts the loader. A trusted kernel which is validated at 
system boot time, usually by a piece of hardware, builds 
the core of the trust hierarchy on which the application 



runs. 



Validating a code image to determine the rightful 
usage of a certificate can be generalized to validating 
any object governed by a certificate. For example, an 
Internet applet, as they are provided for World Wide 
Web applications through the JAVA programming lan- 
guage, could also take advantage of the scheme 
described herein. Thus, any object to be used or 
accessed could be accompanied by a certificate. The 
validation step is very similar to the steps performed by 
a trusted load subsystem for code images. 

Cryptographic unit validation describes the process 
by which the application requesting cryptographic serv- 
ices is assured about the identity of the cryptographic 
unit. There are several methods which can accomplish 
this task. 

Challenge the cryptographic unit. In this method, 
the application issues a puzzle to the cryptographic 
unit that only the cryptographic unit can resolve. 
The fact that the cryptographic unit can solve the 
puzzle is proof of the identity of the cryptographic 
unit. 

The cryptographic unit prepares the application to 
function. In this approach, the application is 
shipped to the target system in a scrambled form. 
For example, the binary image could be encrypted. 
Only a cryptographic unit that has the correct 
decryption key can unscramble the application, and 
hence is a valid cryptographic unit. 

The second method has additional applicability for 
software copyright schemes. Sending the application in 
encrypted form to the target side and letting the crypto- 
graphic unit decrypt the program does not only reveal 
that the cryptographic unit is a valid cryptographic unit, 
but also allows the software manufacturer to send out 
an application tailored to that particular cryptographic 
unit, i.e. host system. Unfortunately, once decrypted the 
application image is available in the clear, it can be cop- 
ied to other systems with little or no effort. 

The invention includes a method, that is referred to 
herein as software level touchpoints, which addresses 
both of the cryptographic unit validation aspects, as well 
as copyright protection schemes. The concept of soft- 
ware level touchpoints is explained in greater detail 
below. 

Application certification is the process of ensuring 
that there is a tight binding between the application 
image and the application certificate issued by the 
application domain authority. The process of application 
certification can be described in two distinct stages. 
They are the installation stage and the execution stage. 
The following is a brief description of these stages. 

Installation stage. The installation stage describes 
the steps necessary to introduce the application 
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and the accompanying certificate to the crypto- 
graphic unit. 

Execution stage. The validation stage describes the 
steps taken to validate the application's identity, s 
based on the certificate passed along with the vali- 
dation request. After successful validation, the 
application enters the execution stage. At any time 
during this stage, the cryptographic unit can issue a 
validation request to revalidate the application's 10 
claim. 

Fig. 8 illustrates the flow of events by which an 
application introduces itself to a cryptographic unit 
according to the invention. Certified applications are is 
introduced to the host system at the application installa- 
tion stage. A certified application consists of the appli- 
cation image, i.e. the code file 65 and the certificate 64 
issued by the application domain authority 60. The 
result of the installation stage is an application creden- 20 
tial 90 which uniquely denotes the application, the cryp- 
tographic unit, and the valid classes of services. The 
result is referred to herein as an application credential. 

The purpose of the install process is to introduce 
the application to the cryptographic unit. A special utility 25 
program, the install program, is called to carry out the 
necessary work. The main task this utility performs is to 
pass a reference to the program image and the applica- 
tion certificate to the cryptographic unit 

Upon receiving the request for installation, the cryp- 30 
tographic unit uses its host system memory access 
capabilities to compute a hash value from the program 
image. The application certificate contains the among 
other information the class of service defined for this 
application. Using these two elements of information, 35 
the cryptographic unit produces a credential which iden- 
tifies the application, e.g. through a name, the hash 
value of the application image, and the class of service 
defined for the application. 

The credential is then signed by the cryptographic 40 
unit and stored in local nonvolatile memory inside the 
cryptographic unit. If desired, the credential is also 
exported to an external area. Because the credentials 
are only useful to the cryptographic unit that generated 
them, it only needs to be ensured that the credentials 45 
have not been tampered with while outside the crypto- 
graphic unit boundaries. 

In the execution stage, an application is loaded by 
the operating system into the memory system and 
starts execution. At some point in the application execu- so 
tion, the application asks for cryptographic services. 
Typically, the first step is to establish a context with the 
cryptographic unit. An application passes the applica- 
tion certificate issued by the ADA to the cryptographic 
unit when it establishes a logical association, e.g. a 55 
cryptographic context. 

Fig. 9 illustrates the steps executed during the exe- 
cution stage according to the invention. The crypto- 



graphic unit 14, upon receiving the request of 
establishing an association, needs to validate the iden- 
tity of the application based on the certificate passed. 
Through the operating system components, the crypto- 
graphic unit has access to the application image, and is 
therefore able to compute the signature of the applica- 
tion. For example, using the DMA capability and the 
knowledge of the memory address range of the applica- 
tion within the memory system, the cryptographic unit 
can compute a hash value. 

After validating the correctness of the certificate, 
the cryptographic unit uses the certificate to locate the 
application credential corresponding to the certificate. 
The credential contains, among other information, the 
computed signature of the application image from the 
installation process described above. If the values 
match, two important facts can be deduced: 

First, the application's identity is established 
because the computed signature over this image 
matches the computed signature at installation 
time. 

Second, the application has not been tampered 
with since the installation stage. 

After this initial validation step, the application can 
issue calls to the cryptographic unit requesting crypto- 
graphic operations. At any time later on, the crypto- 
graphic unit may decide to execute the validation 
process again. The options range from validating on a 
periodic base to validating on each request. 

From an operating system perspective, no changes 
to the loader and the operating are required to imple- 
ment this scheme. The only requirements needed are 
the ability to access the memory image of an object. 
Implementations may however decide to invoke the 
cryptographic unit at application load time to perform 
the validation step. 

The scheme described above is readily extended to 
cover not only code images, but also any kind of data 
object which can make use of the validation method out- 
lined. For example, the operating system itself, subsys- 
tem libraries, and static configuration information could 
be protected from unauthorized modifications or 
replacement by using the scheme described herein. 

Software touchpoints are areas of data that are not 
usable to the host system environment until preproc- 
essed. One example of a software touchpoint includes 
the instruction sequences in a code image which have 
been transformed in a way such that the instruction 
fetch unit of the host system cannot decode them suc- 
cessfully. Similarly, there could be data areas which 
have been altered in a way that the original data is not 
accessible. 

Fig. 10 is a schematic representation of a software 
touchpoint according to the invention. A software touch- 
point 100 is characterized by a starting address 101 
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within the address range of the object and the length of 
the touchpoint. There are several classes of software 
touchpoints: 

Data level touchpoints describe an area inside a s 
data object. No further information about the touch- 
point is recorded in the data object about this touch- 
point. A separate area describes these touchpoints 
outside of the data object. 

10 

Instruction level touchpoints describe touchpoints 
inside an instruction stream. There are two sub 
classes. 

The first subclass describes instruction level is 
touchpoints similar to their data level counter- 
parts. In this case, an area in the instruction 
stream is replaced by the touchpoint informa- 
tion. 

20 

The second subclass describes instruction 
level touchpoints that have a structure. A struc- 
tured touchpoint starts and ends with a special 
instruction which demarcates the touchpoint 
area 103. 25 

All these types of touchpoints are described in 
more detail below. 

The are two types of instruction level touchpoints: 

30 

The first type of instruction level touchpoint imple- 
ments an instruction level touchpoint as a data area 
in the instruction stream which has be replaced by 
a scrambled version. No further information is avail- 
able about the touchpoint at the location itself. 35 

The second type of instruction level touchpoint 
implements the touchpoints with a distinct instruc- 
tion at the beginning and an instruction at the end of 
the touchpoint area. To distinguish the two touch- 40 
point areas, the first type of touchpoint is referred to 
herein as an unstructured touchpoint, while the 
second type of touchpoint is referred to as a struc- 
tured touchpoint. 

45 

Fig. 10 is a schematic representation of a software 
touchpoint according to the invention. The touchpoint 
103 is situated within a software object 100 having an 
address range start 101 and an address range end 102. 

Fig. 11 is a schematic representation of a unstruc- so 
tured and a structured instruction level software touch- 
point according to the invention. For example, a tp_start 
110 arid tp_end 111 instruction could demarcate a 
touchpoint area 103. The information between is the 
touchpoint data to be transformed to the original instruc- ss 
tion sequence. In the case of an instruction level touch- 
point, the data between comprises instructions. The 
demarcation instruction could trap to the cryptographic 



unit to resolve the touchpoint area and put it back into 
place again after the instruction sequence has been 
executed. The sequence of instructions inside the 
demarcated area is a sequence of instructions which 
should be executed atomically.By this, it is ensures that, 
except for operating system exceptions, no other code 
can be executed which could have access to the touch- 
point area 103. 

Alternatively, this touchpoint may be implemented 
as a decoding function inside the instruction fetch unit of 
a CPU. A policy register could store the necessary 
decoding key for this application in a context switch. 
Benefits M this approach include the transparency of 
the touchpoint, combined with the benefit of making the 
code unusable for another system. 

Similar to the unstructured instruction level touch- 
point, any kind of constant data can be protected by this 
scheme. 

Cryptographic Unit Validation Process. Applications 
need to be assured about the correctness of the crypto- 
graphic unit. The objective is to avoid the scenario in 
which application requests are redirected to a different 
cryptographic function. The cryptographic unit valida- 
tion process describes the steps taken to assure the 
application about the identity of the cryptographic unit. 
The validation process described below uses the soft- 
ware level touchpoints herein described. 

Cryptographic unit validation proceeds in three dis- 
tinct stages: 

Manufacturing stage. The manufacturing stage 
describes the steps that need to be taken at the 
application manufacturer side to create an applica- 
tion having the software level touchpoint informa- 
tion incorporated therein. 

Installation stage. The installation stage describes 
the steps necessary to introduce the application 
and the accompanying certificate to the crypto- 
graphic unit. Depending on the type of installation, 
the software level touchpoints may be removed at 
this stage or left intact within the application image 
to be resolved at execution time. 

Validation stage. The validation stage describes the 
steps taken to validate the applications identity 
based on the certificate passed along with the vali- 
dation request. After successful validation, the 
application enters the execution stage (discussed 
above). At any time during this stage, the crypto- 
graphic unit can issue a validation request to revali- 
date the application's claim. In addition to these 
application certification steps, the software level 
touchpoints installed in the application need to be 
removed or transformed dynamically as they are 
encountered by the host system processor. This is 
only the case if they have not been removed during 
the installation stage. 



10 



SDOCIO: <EP 0B28208A2_L> 



19 



EP 0 828 208 A2 



20 



The cryptographic unit validation process outlined 
below allows for additional benefits that go beyond the 
main goal of cryptographic unit validation. From a soft- 
ware manufacturers perspective, copyright protection is 
becoming increasingly critical in a networked world. A 5 
software manufacturer therefore would like to be 
assured that the software shipped to a customer is not 
copied to another system. The range of requirements 
can range from ensuring that the software is loaded to 
only a valid group of authorized systems to customizing to 
the software for exactly one system. 

Fig. 12 is a block schematic diagram that illustrates 
the steps executed during the manufacturing stage 
according to the invention. In the manufacturing stage, 
the application 65 is produced by the application manu- 15 
facturer 120. The objectives are to build an application 
which can be tailored for the particular group of target 
systems or a single target system. Target system is 
identified by the cryptographic unit installed therein. 

The application manufacturer first develops the 20 
application. This is the executable version of the appli- 
cation for the target host system platform. Before the 
application can be shipped to the target host system, a 
customize step 122 installs the software level touch- 
points. After the installation, the application 165 is 25 
shipped. The customize component shown in the figure 
above is responsible for installing the touchpoints in the 
application image. 

The ADA is the domain authority in which the appli- 
cation manufacturer resides. The ADA 60 is granted a 30 
class of services 123 by the SDA 62 which define the 
function used to install the touchpoints into the applica- 
tion image. 

Part of the touchpoint installation is to produce a list 
of locations and lengths of the touchpoint areas within 35 
the code image. In the case of unstructured instruction 
level touchpoints, this information is needed to locate 
the touchpoints. For structured instruction level touch- 
points, this information is not strictly necessary. There 
are also considerations concerning exactly where a 40 
touchpoint could be placed and what the length of the 
sequence should be. For unstructured touchpoints the 
question of where exactly they are placed in the code 
image is of no real importance. 

Technically the touchpoints can be placed into any 45 
area of the image. For structured touchpoints, there are 
more constraints. Restrictions could be that touchpoints 
should for example not cross procedure boundaries, or 
do overlay more than one basic block of instructions. 
The restrictions depend on the nature of the hardware so 
level support for structured touchpoints. Some of these 
aspects are discussed below in connection with hard- 
ware support for software level touchpoints. 

At the end of the manufacturing stage, there is an 
application image augmented with software level touch- ss 
points. The touchpoints are put into the image in a right- 
ful way because the COS was enabled for the 
cryptographic unit by the customized component in 



accordance with rights granted by the SDA to the ADA 
of the application manufacturer. This process, at this 
point, does not involve information about the target sys- 
tem. Any installation which has the capabilities to 
reverse the touchpoint information install process can 
derive a working application. A further tailoring down of 
the target system, would require additional knowledge 
about this system. Because this introduces a tighter 
dependency between the manufacturer and the target 
recipient, a higher effort is necessary on the administra- 
tion side. 

This following discussion first introduces the more 
general case of a certain level of independence 
between the manufacturer and the target system. 
Thereafter, the topic of this tight binding is discussed in 
more detail. 

The installation stage describes the steps taken at 
the target site, i.e. the host system with a specific cryp- 
tographic unit, that are necessary to prepare the usage 
of the application on this system. Again, there are sev- 
eral objectives. 

The first objective is to ensure that an application is 
assured about the integrity of the cryptographic unit. 
This assurance is achieved by that fact that only a cryp- 
tographic unit which was granted the necessary COS to 
process the application image is able to transform this 
image in to a usable one successfully 

The second objective is to ensure that once an 
application is installed on the target system it is only 
usable by this system and cannot be copied to another 
system. 

Fig. 13 is a block schematic diagram that illustrates 
the steps executed during the installation stage accord- 
ing to the invention. The installer component 130 is 
responsible for installing the application in the target 
system. As a part of the install process, the application's 
credential 132 which describes the COS is created. The 
details of this process have been explained above in 
connection with application certification. The other part 
of the install process performs the steps necessary to 
prove that this is a valid cryptographic unit and to build 
an application image which cannot be used other than 
in combination with the cryptographic unit that was used 
by the install process. 

The SDA 62 grants the ADA 60 the set of COS 123. 
The ADA grants the application rights to a set of COS. 
The policy 12 contains the valid COS for the ADA and 
the COS for the installer as it was granted to the ADA of 
the application manufacturer. The installation compo- 
nent 1 30 can therefore only process the touchpoints in 
the application image if it was granted the COS to do so. 

Touchpoints can in theory be removed at the instal- 
lation stage. However, removing them from the applica- 
tion image at this stage has two consequences. First, 
the application has only the one time assurance that the 
cryptographic unit is a valid cryptographic unit at instal- 
lation time. After the removal of touchpoints another 
cryptographic unit could be installed along with another 
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policy card or be bypassed when the application 
requests cryptographic services. Second, without the 
touchpoints the application is in the clear and can be 
copied and executed on any other system. To prevent 
these scenarios, the touchpoint should be removed as 
late as possible in the execution cycle. 

In the execution stage, the application runs on the 
host system. The operating system loader transforms 
the application file image into the executable memory 
image. One part of the process deals with the require- 
ment of validating that the application has not been tam- 
pered with since installation time and rightfully requests 
a certain class of service. The steps taken to ensure this 
have been described above in connection with applica- 
tion certification. For the cryptographic unit validation 
portion, additional steps are required. 

Fig. 14 is a block schematic diagram that illustrates 
the steps executed during the execution stage accord- 
ing to the invention. At application load time (via a 
loader utility 140 and a processing element 142) two 
main objectives need to be addressed. The first objec- 
tive to validate the cryptographic unit. This task is 
accomplished by means of the cryptographic unit 14, 
which is able to resolve the software touchpoints from 
the application. For, example if the cryptographic unit is 
able to compute the original signature of the application 
without the touchpoints, it proved that it can successfully 
remove them and is therefore a valid cryptographic unit 
because it was granted the COS to perform this opera- 
tion. The second objective is to resolve the touchpoints. 
The cryptographic unit is responsible to remove the 
touchpoints before the application portion that contains 
them is executed. 

The simplest case is for the cryptographic unit to 
remove the touchpoints from the application code 
image. The file image of the program still contains the 
touchpoints and stays useless if copied to another sys- 
tem. The memory portion is however in the clear and 
could be copied if a malicious user writes a copy pro- 
gram which constructs the file image from the memory 
image. Such a task would require some skill set and 
knowledge of the underlying operating system, but is 
not impossible. 

Another approach is to leave the touchpoints in 
place and resolve them as they are encountered. This 
approach relies on some hardware support to detect the 
touchpoints. Scenarios for this kind of touchpoint reso- 
lution are described above in connection with hardware 
support for software level touchpoint. 

Tailoring To A Unique Cryptographic Unit. The proc- 
ess described so far does not establish a close relation 
between the software manufacturer's software compo- 
nent and the target system identified by the crypto- 
graphic unit in which it is installed. The benefit of the 
rather loose coupling permits the manufacturer to pro- 
duce an application which can be installed on any sys- 
tem that has the capability to process the touchpoints 
installed inside the application. No further knowledge 



about the target system is required. 

If a more tight binding is desired, the application 
manufacturer needs to tailor the application component 
to the target system cryptographic unit. This could be 

5 done, for example, by creating a unique COS which is 
shared between the manufacturer's ADA and the SDA. 
The SDA installs the unique COS on the policy card 
when it is customized for the target system crypto- 
graphic unit, and shares that COS with the ADA of the 

10 application manufacturer. Only the installation utility on 
the target system which is granted that unique COS can 
successfully install the software on the target system. 

Host System Hardware Support for Certification 
and Cryptographic Unit Validation. Software level touch- 

15 points can take advantage of hardware support from the 
host system CPU. Fig. 15 is a block schematic diagram 
that illustrates the memory hierarchy with respect to the 
software touchpoint resolution according to the inven- 
tion. The host system 16 includes processor registers 

20 files and a cache subsystem 151 that are separated by 
a trust boundary 152 from a memory subsystem 153 
and a disk subsystem 154. It should be appreciated that 
the system architecture shown herein is provided for 
purposes of example and that the invention is readily 

25 applied to other system architectures. 

The following describes the host system processor 
mechanisms needed to support an implementation. The 
main concept is to bring the resolution process of touch- 
points closer to the host system processor execution 

30 elements. By moving the resolution process close to the 
processor, e.g. the cache subsystem, no touchpoint 
areas in the clear are in the main memory system or 
storage elements at a lower level in the memory hierar- 
chy. 

35 There are two main approaches for dealing with 
software level touchpoints: 

In the first approach the host processor generates 
an exception upon detection of a software touch- 
40 point which invokes the cryptographic unit to 
resolve the software touchpoint 

The second approach is similar to the first 
approach, except that it uses the host system 
45 processing elements for the actual operations. 

Both approaches can further be subdivided accord- 
ing to structured versus unstructured software touch- 
point. 

so The Trap to Cryptographic Unit Approach for Struc- 
tured Instruction Level Touchpoints. In the trap to cryp- 
tographic unit approach, the host system processor 
raises an exception when encountering a touchpoint 
start instruction. The exception handler invokes the 
55 cryptographic unit component to remove the touchpoint 
and replace the touchpoint data with executable instruc- 
tions. The host system processor then continues to exe- 
cute the application. Upon detecting the touchpoint end 
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instruction, the host system processor traps again and 
the cryptographic unit can transform the memory image 
back to the touchpoint state. 

Fig. 16 is a block schematic diagram that illustrates 
the memory hierarchy with respect to the software s 
touchpoint resolution according to the invention. The 
host system processor 161 uses the tp_start instruction 
to raise an exception which causes the cryptographic 
unit 14 to be invoked. The cryptographic unit is then 
given the knowledge of the memory address range and 10 
the memory location of the touchpoint 103, and trans- 
forms the touchpoint body into an instruction sequence 
which can be executed by the host system processor. 
Control then returns back to the host system processor. 

Once the touchpoint is translated in this fashion, 15 
other application instances could potentially access the 
touchpoint area. It is therefore important to implement 
the touchpoints as a critical section which no application 
context switching allowed inside this section. Upon end- 
ing the touchpoint instruction sequence, the tp_end 20 
instruction causes a trap to the cryptographic unit which 
allows the cryptographic unit to reverse the touchpoint 
data back to its original state. 

Use of Host System Processor Elements for Struc- 
tured Instruction Level Touchpoints. This approach 25 
assumes that the host system processor has a built in 
logic component which allows it to transform the decode 
the touchpoint during instruction fetch. Upon encounter- 
ing a touchpoint start instruction, the host system proc- 
essor translates the touchpoint data within the 30 
processors cache and continues the execution. No 
memory image changes take place. Upon encountering 
the touchpoint end instruction, the cache line is flushed 
or left for future use. To support this scheme, touch- 
points are required to align on a cache boundary and be 35 
a multiple of the cache line size. 

Fig. 1 7 is a block schematic diagram that shows 
instruction level touchpoint support inside the host sys- 
tem processor according to the invention. Upon detect- 
ing a tp_start instruction by the host system processor 40 
instruction fetch unit 171, the host system first fetches, 
and then transforms, one or more cache lines that con- 
tain the touchpoint area using the key stored in a host 
system processor control register 172. Each application 
may have a different tp_reg value for resolving the 45 
touchpoint area. The tp_reg value is part of the COS-TP 
which is used to install the application in the host sys- 
tem. The loading of the tp_reg control register at context 
switch involves the cryptographic unit as the keeper of 
the information. The key_reg value could also be made bo 
part of the application context state, so that it can be 
loaded during a context switch without invoking the 
cryptographic unit. 

Approaches for Unstructured Instruction Level 
Touchpoints and Data Level Touchpoints. Both unstruc- 55 
tured instruction level touchpoints and data level touch- 
points are characterized by the absence of any meta- 
information about the touchpoints at the touchpoint 



location itself. The approach for this class of software 
touchpoints can be subdivided into two steps: 

The first step involves the detection of these touch- 
points; 

The second step involves resolving the touchpoints 
before the host system processor accesses that 
area. 

To detect a touchpoint area, mechanisms have to 
be put into place in both the software environment and 
the hardware to propagate the information about the 
location of the touchpoints to the host system process- 
ing elements. For example, if the granularity of the 
touchpoint areas is chosen to be on a page size of the 
virtual memory system of the host system, the informa- 
tion about the touchpoint location could be communi- 
cated trough the page tables and translation look aside 
buffers to the host system processor. 

During address translation, the host processor can 
detect whether the address range to be translated con- 
tains software touchpoints or not. When loading the 
cache line for execution or access from a touchpoint 
page by the host system processor, the touchpoint area 
is resolved in the cache subsystem (as described 
above). Similar techniques apply, in which the resolved 
touchpoint areas are kept in the cache lines and are not 
accessible in main memory or the disk images of the 
objects that contain them. Read only cache lines are 
flushed whenever they are no longer needed. Cache 
lines modified need to be transformed back before they 
are written back to the main memory system. 

Although the invention is described herein with ref- 
erence to the preferred embodiment, one skilled in the 
art will readily appreciate that other applications may be 
substituted for those set forth herein without departing 
from the spirit and scope of the present invention. 
Accordingly, the invention should only be limited by the 
Claims included below. 

Claims 

1. An apparatus for certifying applications, compris- 
ing: 

a security domain authority (62) for granting at 
least one class of service to an application 
(65); 

an application domain authority (60) for receiv- 
ing said class of service (63) granted by said 
security domain authority; and 
at least one application certificate (64) issued 
by said application domain authority to applica- 
tions that belong to an application domain 
authority domain. 

2. The apparatus of Claim 1 , further comprising: 
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a processing unit (14) for receiving said appli- 
cation certificate to determine whether said 
application has a right to access a requested 
function. 

5 

3. The apparatus of Claim 2, further comprising: 

a policy (12) that enables said processing unit 
for said granted class of service, wherein any 
mismatch between said policy and said 10 
processing unit invalidates said processing 
unit. 

4. An apparatus for certifying applications, compris- 
ing: 75 



at least one application certificate (64) issued 
by an application domain authority (60) to at 
least one application (65) that belongs to an 
application domain authority domain, said 
application certificate uniquely denoting said 
application, a target processor (14), and/or a 
valid class of services (68) for said application; 
and 

a target processor (14) for receiving said appli- 
cation certificate to determine whether said 
application has a right to access a requested 
function. 

5. The apparatus of any of Claims 1 to 4, said applica- 
tion certificate comprising: 

an application ID (67); and 

a grant of said valid class of services (68). 

6. The apparatus of any of Claims Ito 5, further com- 
prising: 

software touchpoints (103) that are not usable 
by a host system environment unless they are 
transformed. 



7. The apparatus of Claim 6, said software touch- 
points further comprising: 

instruction sequences in a code image which 
have been transformed in a way such that an 
instruction fetch unit (171) of said host system 
(16) cannot decode them successfully. 

8. The apparatus of Claim 6, said software touch- 
points further comprising: 

data areas which have been altered in a way 
that original data is not accessible. 

9. The apparatus of Claim 6, said software touch- 
points further comprising: 



20 



25 



30 



35 



40 



data level touchpoints that describe an area 
inside a data object. 

10. The apparatus of Claim 6, said software touch- 
points further comprising: 

instruction level touchpoints that describe 
touchpoints inside an instruction stream, where 
either an area in the instruction stream is 
replaced by said touchpoint, or where said 
touchpoint is structured to start and end with a 
special instruction which demarcates a touch- 
point area. 

11. The apparatus of any of Claims 1 to 10, wherein 
said target processor is a cryptographic unit (14) 
that does not provide any cryptographic functions in 
the absence of said policy. 

12. The apparatus of Claim 6, said software touch- 
points further comprising: 

software level touchpoints that prevent an 
application image from being copied to another 
system. 

13. The apparatus of any of Claims 1 to 12, further 
comprising: 

a class of service token (65) which serves as 
an installation token to allow installation of an 
application on a particular host system identi- 
fied by the target processor. 

14. The apparatus of any of Claims 1 to 12, further 
comprising: 

a class of service token (65) which is issued by 
said security domain authority to ensure that 
only a specified class of target processors hav- 
ing a specific class of service is authorized. 



15. The apparatus of Claim 6, wherein said software 
touchpoints are used to allow installation of an 

45 application only on host systems that are identified 
by a target processor. 

16. The apparatus of Claim 6 t wherein said software 
touchpoints are resolved in a host processing ele- 

50 ment. 

17. The apparatus of Claim 6, wherein said software 
touchpoints are resolved at a cache level in a host 
processing system memory hierarchy. 



55 



18. The apparatus of Claim 6, further comprising: 
policy control elements (153); and 
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resolution elements (151) for said software 
touchpoints; 

wherein said resolution elements are 
separated from said policy control elements. 

5 

19. The apparatus of any of of Claims 1 to18, further 
comprising: 

a trap mechanism (1 71 , 1 72) for triggering acti- 
vation of said target processor from an instruc- 10 
tion stream. 



20. The apparatus of Claim 6, said software touch- 
points further comprising: 

15 

a structured software level touchpoint identified 
by a start/stop instruction pair. 



21 . The apparatus of Claim 20, wherein said structured 
software level touchpoint identified by a start/stop 20 
instruction pair is executed as an atomic sequence 

of operations. 

22. An apparatus for processing unit validation in which 

an application that requests processing services is 25 
assured about the identity of said processing unit, 
comprising: 

means (74) for challenging said processing 
unit; and so 
means (60) for issuing a puzzle to said 
processing unit that only said processing unit 
can resolve, wherein said processing unit's 
ability to solve said puzzle is proof of the iden- 
tity of said processing unit. 35 



40 



45 



50 
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